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[0040] As can be understood from Table 2, when applied to the demand data, forecaster 

170 could predict that 60 people might demand a $100 ticket for an A-C itinerary, 90 people 
might demand a $90 ticket for the A-C itinerary, 30 might demand a $120 ticket for an A-C-D 
itinerary and so on. The set of demands contained in Table 2 can be represented by and stored 
as demand data structure 200 of generic revenue management data model 125. It should be 
recalled that airline network 300 includes only an A-C, B-C and C-D flight, whereas in the case 
of an actual airline, the number of resources would be much greater, leading to hundreds of 
thousands or millions of demands. 

[0041] The demands listed in Table 2 might only be satisfied by particular resource 

bundles. Table 3 associates or links each demand to the resource bundles that satisfy that 
demand. For simplicity each demand is described only in terms of the itinerary and fare class 
(the first and second columns of Table 2). The third column lists the resource bundles from 
Table 1 that can satisfy each demand. 



Table 3 


Itinerary 


Fare class 


Resource Bundles from 
Table 1 That Satisfy 
Each Demand 


A-C 


1 


A-C 


A-C 


II 


A-C 


A-C-D 


1 


A-C-D 


A-C-D 


II 


A-C-D 


B-C 


1 


B-C 


B-C 


II 


B-C 


B-C-D 


1 


B-C-D 


B-C-D 


II 


B-C-D 


C-D 


1 


C-D 


C-D 


II 


C-D 



[0042] As illustrated by Table 3, the A-C resource bundle satisfies both the fare class I 

and fare class II demands for a flight from A to C, the A-C-D resource bundle satisfies both the 
fare class I and fare class II demands for a flight from A to D via C, and so on. In this example, 
the A-C and C-D resource bundles would not be linked together to satisfy the A-C-D demands 
because all of the A to C to D itineraries are encompassed by the A-C-D resource bundle, as 
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there are only three flights offered in airline network 300. Furthermore, the A-C-D resource 
bundle would not satisfy the A-C demands, because from the perspective of the network, the 
passenger demanding an A-C-D ticket, regardless of if they debarked at C, would place a 
demand to proceed to D. The linkages between resource bundles and demands represented in 
Table 3 can be represented by and stored in database 123 as resource bundle to demand link 
data structure 230 of generic revenue management data model 125. 

[0043] Based on the information stored in demand data structure 200, resource data 

structure 210, resource bundle data structure 220 and resource bundle to demand link data 
structure 230, a revenue management software program could perform a network optimization. 
For example, demand to come linear programming could be applied to generic revenue 
management data model 125 in order to determine which resource bundles should handle 
which demands. Additionally, a revenue manager could apply an algorithm to generic revenue 
management data model 125 in order to decompose the network and determine the resource 
demands. The resulting resource demands could be represented by and stored in database 
123 as resource demand data structure 240. Altematively, if sufficient information was available 
about the demands on each resource, resource demand data structure could be populated with 
that information. Based on the contents of resource data structure 210 and resource demand 
data structure 240, a revenue management software program could then apply a local 
optimization scheme to the data in generic revenue management data model 125. In the case 
of airline network 300, this might entail applying an EMSR algorithm to generic revenue 
management data model 125. The EMSR could be used to determine how many seats on each 
plane should be reserved for fare class I and/or fare class II passengers and are what price the 
tickets should be sold. 

[0044] As can be understood from Figure 3 and the accompanying discussion, the data 

structures in generic revenue management data model 125 can be used to represent and store 
revenue management problems. In Figure 3, a simple airline network was chosen as the 
primary example because many revenue management concepts and algorithms are developed 
in the context of the airline industry. However, generic revenue management data model 125 is 
industry independent and can be applied to a wide variety of markets. For example, generic 
revenue management data model 125 could be used to represent revenue management 
problems for the broadcasting industry. In broadcasting, a resource could be an advertising 
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time slot, the demand could be the demand to show different commercials and a resource 
bundle might be a set of commercial time slots in certain types of shows. The resource bundle 
to demand links could be determined from the demands placed on the resource and the 
resource bundles offered by a broadcaster. As would be understood by one of ordinary skill in 
the art, generic revenue management data model 125 can thus be used to represent revenue 
management problems from many different industries. 

[0045] Referring now to Figure 4, one example of entity relationship diagram 400 is 

shown for one embodiment of a database incorporating generic revenue management data 
model 125 for revenue management in a transportation revenue industry. In entity relationship 
diagram 400, data set entity 405 can be used to distinguish multiple data sets, thus allowing 
several data sets to be maintained simultaneously. Data set entity 405 can contain a data set 
ID so that the various data sets can be appropriately identified. If a revenue manager was 
servicing multiple clients at the same time, data set ID could ensure that the different data sets 
would not be combined or commingled. 

[0046] Total demand entity 410 can represent the total demand placed on a network. 

Total demand entity 410 can include a data set ID to associate the total demand with 
appropriate data set, a total demand ID to identify the total demand and a fare value to 
represent the revenue realized for each unit of total demand satisfied. The total demand can be 
based upon a demand function, represented by total demand function entity 415. Total demand 
function entity 415 can include a data set ID for associating the function with the appropriate 
data set, a total demand ID to associate the total demand function with the appropriate total 
demand and a function type to describe the demand function. 

[0047] The demand function associated with demand function entity 41 5 can depend 

upon various parameters. Each of these parameters can be represented by a total demand 
function parameter entity 420, which can include a data set ID to associate the parameter with 
the appropriate data set, a total demand ID to associate the parameter with the appropriate total 
demand function, a function type to identify the name of the function type using the parameter, a 
parameter name to provide a unique name for each parameter and a parameter value to 
quantify the parameter. 

[0048] In addition to being dependent on a total demand function, the total demand can 

be dependent on a time pattern. The time pattern can be represented by total demand time 
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